Instructions for creating a new hack file:

	Here is the basic format for a hack file:


<?xml version="1.0" encoding="UTF-8"?>
<document>
<warning>
	I am the text that will pop up when this item is checked
</warning>
<comment>
	I am the text that will appear in the program's Help->Hacks window
</comment>
<hackblock>
	<identifier><![CDATA[
		<!-- I am the search string -->
	]]></identifier>

	<replacement><![CDATA[
		// I am a few lines of replacement text.  You can put code here.
		// I am a few lines of replacement text.  You can put code here.
		// I am a few lines of replacement text.  You can put code here.
	]]></replacement>
</hackblock>
</document>


	Use the current hacks in the hacks directory as an example for setting up a new file.

	The name of the xml file is the text that will show up in the hacks list in Hack Builder.  The list is processed top to bottom, so hacks higher up on the list will get added before lower ones.  This is useful if a hack needs to prevent another hack from being added because they conflict.

	The <identifier> line is the text that will be searched for in data/mainBase.xml.  Make sure that the text you use for an identifier is either a comment (xml or javascript) or programatically correct.  It will be left in the file if your hack is not chosen.

	If the hack is selected, then when building begins, the identifier line will be replaced by the contents of the <replacement> block.  Note that the identifier text will be deleted and replaced if this hack is selected.

	Please make sure that all <identifier> and <replacement> blocks use the CDATA wrapper* (see note below).

	You may create as many <hackblock> sections as you like.

	The <comment> block is used to dynamically populate the Help->Hacks... list.  Please only have one <comment> block per file.

	The <warning> block is used to pop up a warning message when a particular hack is selected.  Please only have one <warning> block per file.



After you've created the hack file:
	
	Go through data/mainBase.xml and insert your identifier lines in the appropriate places.



Adding new functions to the drop-downs for button remapping:
	
	Add the new function name to data/functions.txt



Once you're done:
	
	Please test your hack.  It's impossible to test all combinations, but I suggest at least testing the following:
		Just your new hack
		No hacks
		All hacks

	Also, pay attention to what the other hacks are.  It's possible that there could be interference between hacks modifying the same functions.  Please make sure any conflicts are resolved by modifying them appropriately... and then test again!




* It is a violation of the xml standard to allow nested CDATA blocks.  However, since the hack files are xml and the text going into them is also potentially xml, I had to make concessions for ease of use.  Therefore, it is ok for your identifier and replacement text to also include CDATA blocks, but do not nest them any further than that, or the reader will not be able to parse it.

Example:


<hackblock>
	<identifier><![CDATA[
		<!-- Tiny Function -->
	]]></identifier>

	<replacement><![CDATA[
		<function id="doStuff"><![CDATA[
					if (a < 0) this.bubble("doOtherStuff");
				]]></function>
	]]></replacement>
</hackblock>
